How to use the version control system

We are using Git, a distributed version control system.

Branches

One important concept of version control systems are branches. They allow developers to develop features independent of each other without getting too many conflicts. The basic idea is that whenever a new feature is implemented, a branch is created in which the feature is developed until it is complete. Then the branch is merged back to the main development branch which in our case is called master. This blog post provides a nice explanation of the branching model.

Besides the master branch, we also have a stable branch which contains the code that has been released to BibSonomy. You can see all current BibSonomy branches on the branches page.

This model requires that every developer must be very careful when merging branches! Therefore, we have restricted the commit rights for the master and stable branches. This means that the features you implement and bugs you fix should always be developed and commited in a separate branch. When you are finished, you contact the responsible senior developer and ask him or her to merge your changes into the master branch. The development model thus is as follows:

1. You get a task from a senior developer.
2. You create a new branch from the master branch and name it according to your feature (see below). Before creating the branch, please update your repository.
3. You regularly commit to that branch and merge changes from the master branch into your branch ("commit early and often"). You also push your changes regularly to Bitbucket. Do not close the branch!
4. When your feature is finished, you contact the responsible senior developer (see 1.) and present the functionality. If everything is alright, he/she will merge your branch with the master branch and close the branch!
5. The cycle starts again at 1. :-)

Please note that this procedure might be changed in the future and might not apply for all tasks (e.g., we have developers who exclusively fix bugs and work on very small features which will still need rights for the master branch).

Branch Names

Dos

• use prefixes for features and bugfixes (features: feature/FEATURE, bugfix/BUGFIX)
• use lowercase
• do not use the issue number in the name
• keep the name short but meaningful

Don'ts

• do not include the ticket number
• avoid special chars (#, öäü, …)

Merging vs Rebase

When someone has commited other changes to your branch, there are two different approaches to combine these changes: Rebasing your commit(s) or merging your commits.

Within branches try to rebase your commit if there are no conflicting changes else merge your changes. Always merge different branches.